Skip to main content

Memory API Reference

The Memory API provides agents with persistent conversational context across multiple interactions. While language models only receive the current prompt, memory providers allow BindAI agents to remember previous messages, user preferences, and conversation history. This page documents the public Memory API.

Overview

Memory stores information beyond a single request. Conceptually:
This allows conversations to feel continuous rather than isolated.

Purpose

Memory enables agents to:
  • remember previous conversations
  • preserve user context
  • personalize responses
  • retrieve historical interactions
  • maintain long-running conversations
Without memory, every request is independent.

Memory Providers

BindAI separates memory through providers.
Different providers may use different storage backends while exposing the same interface.

Assigning Memory

Memory is typically attached to an agent. Conceptually:
Once attached, the agent automatically reads and writes conversation history.

Reading Memory

Before generating a response, the agent retrieves previous messages.
The retrieved context becomes part of the model input.

Writing Memory

After responding, the interaction is stored.
Future requests can access this information.

Conversation History

A memory provider typically stores a sequence of messages.
The exact storage format depends on the provider implementation.

Session Isolation

Memory is generally organized by conversation or session.
Separate sessions should not share conversational history unless explicitly configured.

Persistence

Some memory providers persist data. Others keep it only during runtime. Examples include:
  • in-memory storage
  • databases
  • key-value stores
  • cloud storage
  • custom implementations
The agent interacts with all providers through the same abstraction.

Clearing Memory

Applications may clear conversation history when appropriate. Typical situations include:
  • user logout
  • conversation reset
  • testing
  • privacy requests
Clearing memory starts a new conversation context.

Memory vs Knowledge

Memory and knowledge solve different problems. Agents often use both together.

Memory in Workflows

Workflow nodes may also access shared conversation memory.
This allows multiple agents within the same workflow to share conversational context.

Error Handling

Memory providers should gracefully handle:
  • unavailable storage
  • missing conversations
  • corrupted data
  • connection failures
Applications should continue operating whenever possible, even if memory is temporarily unavailable.

Performance

Efficient memory providers should:
  • retrieve only relevant history
  • avoid unnecessary database queries
  • support scalable storage
  • minimize serialization overhead
Large conversation histories may require summarization or truncation.

Security

Conversation memory may contain sensitive information. Providers should:
  • encrypt stored data when appropriate
  • isolate user sessions
  • respect privacy policies
  • support data deletion
  • restrict unauthorized access
Security requirements depend on the deployment environment.

Best Practices

  • Use memory only when conversational continuity is required.
  • Keep sessions isolated.
  • Limit the amount of retrieved history.
  • Store only necessary information.
  • Clear memory when conversations end.
  • Choose a provider appropriate for your deployment.
  • Combine memory with knowledge retrieval when needed.

Related APIs

The Memory API integrates with:
  • Agent
  • Project
  • Workflow
  • Knowledge
  • Provider
These components together enable context-aware AI applications.

Summary

The Memory API enables BindAI agents to remember previous interactions across multiple requests. By separating memory into interchangeable providers, BindAI supports everything from simple in-memory conversations to scalable persistent storage while keeping agent behavior consistent and provider-independent.